Well known technologies exist for broadcast of messages to users in cellular networks and to provide authenticity and integrity protection for such messages. The combination of integrity protection and authentication will be referred to hereinafter as authentication or message authentication. Examples of such systems include the Multicast Broadcast Multimedia System (MBMS) specified by 3GPP (TS 33.246), Cell Broadcast System (CBS) (TS 23.041 v11.0.0 and TS 23.401 v10.4.0), and the Public Warning System (PWS) for which security is currently being specified (http://www.3gpp.org/ftp/tsg sa/WG3 Security/TSGS3 63 Chengdu/Docs/S3-110565.zip).
In a broadcast setting, source origin authentication is necessary. This is usually achieved by adding a public key digital signature of the message to the message. Examples of other mechanisms used include those based on pre-shared keys, and on hash-chains (e.g. IETF RFC 4082).
When a public key digital signature is added to the message, the receiver can verify that the signature is correct and hence deduce that the received message is also correct. The receiver may further deduce that the message originates from the sender claiming to be the origin of the message.
Security features such as message authentication are normally handled by a two stage process by security protocols. In a first negotiation phase, traffic is not protected between the sender and the receiver. During this phase, the sender and receiver agree on which security features are supported by each side. They negotiate which of these security features are to be used, together with possible parameters to configure each chosen security feature. For example, if a signature is to be added to a message, the sender and receiver could agree on which algorithm to use for the signature computation. In the simplest form of negotiation, the sender of the message informs the receiver which security feature to use. In this situation the sender will have selected the security feature and its configuration from an assumed set of supported features or from a list of features and configurations previously obtained from the receiver.
Once the security features are selected and configured, they have to be activated for messages sent from the sender to the receiver.
This can be done in several ways. One example is provided in 3G and LTE telecommunication networks as defined by 3GPP (TS 33.102 v10.0.0, TS 33.401v10.4.0). In such networks, the network sends a “security mode control message” to the terminal to instruct the terminal to start security processing of the messages. Before the security mode control message is sent the traffic is not protected. Another example is provided by IPsec (IETF RFC 4301), in which two peers run IKEv2 (RFC 4306) during the negotiation phase. When that is completed, traffic between the two peers starts to be integrity protected (if that feature was selected during the negotiation).
Typically, when communication systems are deployed it can be expected that both the sender and the receiver of a message implement the functionality needed. For example, if the sender includes some control information in a message, the receiver is expected to be able to interpret the control information and take any action associated with it.
Another option is that there may be a mechanism in which the sender and receiver agree on which functionality will be supported, and after this they only include information relating to the agreed functionality in the messages.
A third option is that receivers are able to distinguish information elements which they do understand and can ignore those for which they have no support.
Systems are often designed and released in a step by step fashion. For example some functionality may be provided in a certain release, with more functionality being added in later releases. This is how telecommunication systems defined by 3GPP are handled.
Due to time schedule and dependencies on other features, a feature is sometimes only partially specified in one release. It may then be decided to include that feature in a certain release with the intention of completing the specification in the next release. This happened to the Public Warning System ETWS (Earthquake and Tsunami Warning System).
The Public Warning System (PWS) is a system for delivery of warning messages from a telecommunication network to terminals/user equipments, such as mobile telephones, laptops, and tablets. The warnings are broadcast in certain areas. A typical type of warning is a warning about an event such as tsunami or earthquake.
In PWS a field was added which was intended to carry the signature of a warning message. However, it was never specified how this signature should be computed and verified. As a result, terminals implemented according to the current specification will receive the signature field, but the content of the field is not known to them and they cannot verify the authenticity of the message.
If the terminal completely ignores the signature field, the terminal is open to attacks. An attacker may inject false messages which the terminal will display to the user. This danger may lead to the development of a proprietary signature scheme which could then be implemented by some (but probably not all) terminals. Terminals could also be developed to interpret the signature field in some other proprietary way.
When 3GPP finally defines a signature scheme to fill the signature field and corresponding actions to be taken by terminals, those terminals using a proprietary interpretation of the signature field in the warning message are likely to deduce that the signature is invalid (because it does not follow the expected proprietary structure). This results in a risk that such terminals will discard the warning message before showing it to the user. In addition, even terminals attempting to implement the signature scheme specified by 3GPP may be incorrectly implemented and may therefore also deduce that the signature is incorrect and discard the warning message.
Since PWS is a safety critical application it is crucial that users get the information provided by the system: this may possibly be even more important than the ability of the system to provide authentication of the messages. Unfortunately, since the signature field is already included in the PWS warning messages, once the signature scheme is added to a 3GPP release, the problems with existing proprietary schemes and incorrect implementations described in the preceding paragraph will become reality. It will be noted that authentication of PWS messages is hence “always on”, i.e. there is no negotiation phase which can be used to disable the feature.